Firstly, I want to ask "Can AppleSoft BASIC programs switch banks, or store data in a memory bank other than the one in which the program itself resides?"
What I want to do is write an AppleSoft Database, and I think (Well actually, I'm certain) it would be easier to make the program really huge if I could allow the databases, their indexes, and configuration data to be stored in another bank of memory.
On the other hand, I'm wondering, if I can stick the database in another bank, how huge should I make the program? I'm already planning on segmentation (one main program that launches four or five other according to selection from a menu) that saves certain temporary data in a text file that gets deleted when the program is completely quit. This way, I don't have to worry about passing parameters between BASIC programs--especially since AppleSoft won't do that.
If other banks can be used at all--for anything (however small the use)--how do I do it?
Path: BASIC/AppleSoft Bank-Switching
Subj: Extra memory for Applesoft 90-12-29 13:32:51 EST
From: Eight bits
Posted on: America Online
You can always store data in textfiles, which you can place in a ramdisk for fast access. When ProDOS 8 boots, it creates a volume entitled /RAM which uses the second 64K memory bank. Applesoft has access to /RAM just as it does to any other online volume. If you have a //gs or a memory card for a //e or //c then you should be able to use even larger ramdisks for temporary data storage.
But if you want direct access to variables without having to read a diskfile, then you should check out a Beagle Bros product called "Extra K." I believe this disconnects the /RAM volume, and instead allows Applesoft the direct use of the second 64K aux memory bank to store its variables. This utility is now available from Beagle free for the downloading, though I'm not sure about redistributing it to others. You could ask over at Beagle's Industry Connection area. I've not used this product myself.
Jerry
Path: BASIC/AppleSoft Bank-Switching
Subj: Extra K, /RAM and AppleSoft 90-12-30 02:03:11 EST
From: Miffed GS
Posted on: America Online
Perhaps I didn't make myself clear. Then again, maybe you didn't attempt to answer the question I most wanted answered, either because I didn't emphasize it enough or ask it incorrectly. Let me try again.
1. If I choose to stick the Database, Indexes, Queries, and Temp.Parms on the /RAM disk, then they'll be listed as files, right? And I will not be able to manipulate them as raw data. How do I deal with the lack of memory that AppleSoft allocates to itself? Should I stick the Data in a specific location in RAM(not /RAM) so that I can deal with it as arrays, or other such variables? Maybe there are some locations in RAM that I can POKE the Variables into so that they don't get dumped during program-switching. But where? and how much space is available?
2. What is the story with AppleSoft memory management, and how should I go about knowing how much space is free and how much space a given Data file will take when it is loaded?
3. Should I give up on AppleSoft BASIC and get a compiler? The reasons I am asking this is because I want to write the program entirely in BASIC if I do so, because I need the program quickly and don't have time to muck around with debugging it in a language that I am new to. Perhaps I'm too dememnted a programmer. ;)
Path: BASIC/AppleSoft Bank-Switching
Subj: More memory for Basic 90-12-30 10:36:56 EST
From: Eight bits
Posted on: America Online
Here are more thoughts, though I'm still not sure I have the answers you are looking for. Hopefully others will help.
1. Yes, data stored on /RAM must be in files, but a random-access file on a ramdisk is not that different from an array. It's true, though, that a program using such files would be slower and more complicated than one using just array variables.
If main memory is big enough to hold your data provided that you segment your programs, then you could use Basic.System's CHAIN command to preserve the variables while switching program segments. However because this uses only main memory, it still may not provide enough space for your needs.
There is no easy way to POKE data into other memory banks directly from Applesoft. (Actually, you could POKE it OK, but couldn't then PEEK it).
I've looked further into Beagle's Extra K program, and it seems to me that it will do what you want - it makes 59K of auxiliary memory available to Applesoft variables, leaving 35K of main memory available for the program. Segmentation is also allowed; that is the variables can be preserved while you switch program segments in main memory.
2. Applesoft's memory management is not very sophisticated. If your data is numeric, then the appropriate space is reserved in advance by the initial DIM statement, and you don't have to worry about it further. Strings are stored dynamically though, and you could run out of memory while loading a large string array from disk. If you are not using Beagle's Extra K then the amount of free memory at any time can be determined with a statement like X=FRE(0). It's probably a good idea to do "fast garbage collection" before this, with a statement like PRINT CHR$(4)"FRE".
3. The newer Basics do provide more available memory, and are really more suitable for this kind of project anyway. Probably Micol Advanced Basic would be best. Remember though, that Beagle's Extra K program is free for the asking. You might want to try this before buying MAB.
Jerry
Path: BASIC/AppleSoft Bank-Switching
Subj: Too Late 90-12-31 23:22:18 EST
From: Wraxtiorre
Posted on: America Online
I just ordered MAB for the IIe. Yeah, sure--I could've bought the IIgs-specific version; but I don't have any proper reference books to GS/OS nor do I have the time/money to get acquainted with it. So, I'm going to deal with ProDOS 8 for now, and when I get a working version up and running, then I'll switch over to ORCA/Pascal and ORCA/M. (What a fool; buying all these compilers for an environment that I don't understand! :(
At least MAB will allow me a great deal more memory to play with--as well as Data structures, named routines, and other such good stuff that Compiled languages are good for. :)
Path: BASIC/AppleSoft Bank-Switching
Subj: More possibilties... 91-01-05 16:12:27 EST
From: GuyKitSink
Posted on: America Online
Here are a few possibilites you might consider:
If you do not need to look at a lot of data at a time, peeks and poke might do the trick for keeping data in RAM (vs /RAM). In our gardebook program "Amazing Window" we didn't have room for arrays, so we set aside 16K of memory for data. By using peeks and pokes we can store numbers up to 64,000+ in just two bytes of memory. We actually only needed to store numbers up 999 in most places so we could use unused bits in the high byte to signify such things as incompletes, excused, etc.
By using /RAM for switching program segments, you can set aside a lot of RAM for data space. We sell a program called MicroDot which frees up RAM for you. BASIC.SYSTEM is a memory hog for what it does. MicroDot replaces BASIC.SYSTEM and is over 7.5k smaller in size so you gain RAM space. It also has the ability to do things like load directory listing into an array at machine language speed. No inputing froma directory and them doing a MID$ to pull out just the filename like in BASIC.SYSTEM. In addition, MicroDot will do BASIC overlays without the clunky chaining. You just tell MicroDot what line number or memory location you want to overlay to and the filename to overlay and it is done. End of Applesoft is reset but LOMEM and HIMEM are unchanged so your variables are in tact. See Kitchen Sink "Direct" in productivity, education or graphics fr details.
